solana: pin builder-stake's bytes, for both networks - #4306
Merged
Conversation
Neither checksum file listed `builder-stake`, and `shasum -c` checks only the files it names, so `make verify-checksums` passed on every change while pinning nothing about this program. The other two programs were covered from the day they landed; this one was added and never added to the list. That is not theoretical. The bytes first deployed to Solana devnet came from a local toolchain and were 9kb larger than the reproducible build, and nothing would have said so. Devnet now runs the artifact: its first 184768 bytes match this checksum exactly, and the rest is the zero padding an upgrade leaves behind when it does not shrink the data account. Verified by flipping one byte of the artifact and watching the check fail.
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The checksum files now include the previously unpinned builder-stake artifact for both networks, which aligns with the stated verification behavior and introduces no functional code-path risk.
Pull request overview
This pull request closes a reproducible-build verification gap in the Solana build pipeline by adding builder-stake to the checksum allowlists so make verify-checksums actually pins its produced .so bytes for both supported networks.
Changes:
- Add
doublezero_builder_stake.soentries to thedevelopmentandmainnet-betachecksum lists used byshasum -c. - Document the checksum coverage fix in
CHANGELOG.md.
File summaries
| File | Description |
|---|---|
| solana/programs/sha256sums_mainnet_beta.txt | Adds the pinned sha256 for artifacts-mainnet-beta/doublezero_builder_stake.so so verification covers it. |
| solana/programs/sha256sums_development.txt | Adds the pinned sha256 for artifacts-development/doublezero_builder_stake.so so verification covers it. |
| CHANGELOG.md | Records that builder-stake is now included in reproducible-build checksum verification. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
bgm-malbeclabs
enabled auto-merge (squash)
September 9, 2026 22:42
martinsander00
approved these changes
Sep 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two lines, one per checksum file. They close a hole that has been open since
builder-stakelanded.What was wrong
make verify-checksumsrunsshasum -a 256 -c programs/sha256sums_<network>.txt, andshasum -cchecks only the files the list names. Neither list namedbuilder-stake:The Dockerfile builds all three programs and exports
target/deploy/*.so, so the artifact was produced on every run and then ignored.solana.ymlhas been runningmake build-checked-artifactsfor both networks on every change, reporting OK, and pinning nothing about this program's bytes.Why it mattered today
The bytes first deployed to Solana devnet came from a local toolchain rather than the pinned Rust 1.91 and Solana v3.0.12 in the Dockerfile. They were 9kb larger and hashed differently:
98faedb2...d7f51884...Nothing would have reported that. Devnet has since been upgraded to the artifact.
Testing Verification
make verify-checksumspasses fordevelopmentandmainnet-beta, all three programs each, against artifacts built bymake build-artifactsin Docker.Flipping one byte of the
builder-stakeartifact makes it fail:Restoring the byte makes it pass again. The first attempt at this wrote a zero over a byte that was already zero and reported OK, which is a reminder that a negative check needs checking too.
The devnet program is the artifact.
solana program dumpreturns 193800 bytes because an upgrade does not shrink the data account; its first 184768 bytes are byte-identical toartifacts-development/doublezero_builder_stake.soand the remainder is zero.The mainnet-beta line is the reproducible hash for that build. Nothing is deployed there.